Summary

Bundle-source (src-bundle) and bundle image builds are single-arch by design and were created without a node selector, so on heterogeneous build clusters the build pod can land on an arm64 node. The build inputs (e.g. pipeline:src) are manifest lists that contain only an amd64 entry for single-arch repositories, so buildah then fails with:

error: error creating buildah builder: choosing an image from manifest list docker://image-registry.openshift-image-registry.svc:5000/<ci-op-ns>/pipeline@sha256:<digest>: no image found in manifest list for architecture "arm64", variant "v8", OS "linux"

This PR pins both bundle build sites (bundleSourceStep.run in pkg/steps/bundle_source.go and the IsBundleImage() branch in pkg/steps/project_image.go) to amd64 nodes via a shared pinBuildToSingleArchNode helper that merges a kubernetes.io/arch entry into the build's node selector (merge rather than replace, so a selector set earlier on the build would survive), matching what constructMultiArchBuilds already does for pipeline builds. A tripwire unit test (TestSingleArchBuildPinMatchesPipelineArchGuarantees) locks the pin to the pipeline-side guarantees it depends on.

Fixes #5328

Why the previous "no node selector" behavior is wrong

The removed comment said the build "will be scheduled on any available node no matter the architecture" — that was written when it was harmless, but since pipeline outputs became manifest lists (#3587, reworked in #5004), the content buildah pulls is resolved by the architecture of the node the pod happens to land on. For a single-arch repo the manifest list has no arm64 entry (amd64 is the only architecture built unless more are configured), so the build's correctness depends on scheduler placement: amd64 node → works, arm64 node → hard failure. All 5 in-run retry attempts can land on arm64 too (FetchImageContentFailed ×5). That is a flake by construction, not a valid "any node" invariant.

Evidence (fail → retry-pass on the same PR/job)

From openshift/oadp-operator#2313:

• pull-ci-...oadp-dev-4.22-e2e-test-cli-aws: FAILURE 2026-07-23 00:48 UTC (exact error above in build-log) → retry SUCCESS 02:34 UTC
• pull-ci-...oadp-dev-4.23-ci-index: FAILURE 2026-07-22 22:40 UTC (same error, then src-bundle failed after 5 attempts ... FetchImageContentFailed) → retry SUCCESS 22:58 UTC
• second ci-index pair the next day: FAILURE 13:19 UTC → retry SUCCESS 13:33 UTC

Farm-wide: search.ci, no image found in manifest list for architecture, build-logs, 24h → 93 job-runs in 24 hours, e.g. kubevirt/hyperconverged-cluster-operator#4421, assisted-service periodic, csi-operator periodic, plus openshift-kni/, medik8s/, lvm-operator.

Why pinning to amd64 cannot break anyone (including additional_architectures repos)

• amd64 is unconditional in every pipeline. additional_architectures is strictly additive — pkg/api/types.go: "AdditionalArchitectures is a list of additional architectures to build for. AMD64 architecture is included by default." There is no knob to remove amd64, and projectDirectoryImageBuildStep.ResolveMultiArch() inserts NodeArchitectureAMD64 unconditionally before adding configured capabilities. So a repo with additional_architectures: [arm64] produces a pipeline:src manifest list containing both amd64 and arm64 — the amd64-pinned bundle build resolves its amd64 entry and works exactly as for single-arch repos. The failing direction (node arch missing from the list) cannot occur in reverse, because no configuration produces a manifest list without an amd64 entry.
• No new scheduling requirement. Every job that builds src already requires amd64 capacity: constructMultiArchBuilds pins src-amd64 (and every other pipeline build) to kubernetes.io/arch: amd64 nodes. If a cluster could not schedule the pinned bundle build, it could not have built src in the first place.
• Bundles are amd64 artifacts by design. ci-operator's bundle/index tooling is amd64-only (index_generator.go: "At the moment, we support only amd64"), and bundle image content is architecture-independent metadata/YAML — the node arch never affects the produced bundle, only whether its inputs can be pulled.
• Guarded by a tripwire test. TestSingleArchBuildPinMatchesPipelineArchGuarantees (in bundle_source_test.go) asserts the invariants above against the real functions: the default constructMultiArchBuilds output targets the pinned arch, ResolveMultiArch() contains it even when only other architectures are configured, multi-arch pipelines still produce a build for it, and pinning merges into (not replaces) an existing node selector. If a future change breaks any link in that chain, this test fails and points back at pinBuildToSingleArchNode.

Test plan

• go build ./pkg/steps/...
• gofmt -l clean
• go test ./pkg/steps/... passes, including new TestSingleArchBuildPinMatchesPipelineArchGuarantees

/cc @droslean

Summary

• Updates the CI bundle build steps so src-bundle and bundle image builds run only on amd64 (stable/amd64) nodes, even when the inputs come from pipeline:src/manifest lists.
• Eliminates intermittent src-bundle failures where buildah pods scheduled onto arm64 couldn’t resolve amd64-only manifest-list inputs.
• Implements the behavior consistently across bundle build paths by introducing/using a shared pinBuildToSingleArchNode helper that pins corev1.LabelArchStable to api.NodeArchitectureAMD64 and merges with any existing NodeSelector:
  • bundleSourceStep.run in pkg/steps/bundle_source.go
  • the IsBundleImage() branch in pkg/steps/project_image.go
• Adds a tripwire unit test (TestSingleArchBuildPinMatchesPipelineArchGuarantees) to ensure the pinned “stable/amd64” invariant remains aligned with the pipeline’s multi-arch manifest-list construction and that selector pinning doesn’t overwrite preexisting selectors.